Amazon CloudWatch AlarmのEvaluationPeriodsとDatapointsToAlarmパラメーターを理解する

#CloudWatch Alarm

るおん

2024.06.06

はじめに

先日CloudWatch Alarmの機能を使ってEC2インスタンスのCPU使用率を監視し、異常を検知した際にSNSを使用してEメール送信するという機能をCDKで実装するという記事を書きました。

【CDK】CloudWatch AlarmでEC2インスタンスのCPU使用率を監視し、SNSでEメール通知を受けとる

その際のCloudWatch Alarmの設定において、EvaluationPeriodsとDatapointsToAlarmというパラメーターを使用して実装しました。

そこで今回は、この二つのパラメーターを設定するとどのような挙動をするのかという説明と検証、そしてその活用法についてまとめてみました。

3行まとめ

EvaluationPeriodsとDatapointsToAlarmとは、特定の期間の一定の異常を検知したい場合に有効である。
クリティカルな異常を即時に検知したい場合はEvaluationPeriodsとDatapointsToAlarmを同じ値に設定する。
アプリケーションの規模と要件に応じてデータポイントの割合を適切に決定する必要がある。

CloudWatch Alarmとは

CloudWatch Alarmは、Amazon CloudWatchの機能の一つで、特定のメトリクスが設定した閾値を超えた場合にアラームを発生させることができます。

これにより、システムの異常を迅速に検知し、適切な対応を取ることができます。

参考：Amazon CloudWatch でのアラームの使用

EvaluationPeriodsとDatapointsToAlarmとは

EvaluationPeriodsとDatapointsToAlarmについて、公式ドキュメントによると

EvaluationPeriods

データを指定されたしきい値と比較する期間の数。アラームをトリガーするために、連続したデータポイント数が違反であることを要求するアラームを設定している場合、この値はその数を指定する。M out of N" アラームを設定する場合、この値は N で、DatapointsToAlarmは M である。(DeepL翻訳)

DatapointsToAlarm

アラームをトリガーするために必要なデータポイントの数。これは「M out of N」アラームを設定する場合にのみ使用する。その場合、この値が M であり、EvaluationPeriodsに設定した値が N となる。(DeepL翻訳)

とのことです。

EvaluationPeriodsはアラームが評価される期間の数であり、DatapointsToAlarmはアラームが発報されるために必要なデータポイントの数です。

つまり、EvaluationPeriodの数のうちDatapointsToAlarmの数において異常が検出されたら、Alarmが発報されるということです。公式ドキュメントに書いてある「M out of N」のうち、Mに当たるのがDatapointsToAlarmで、Nに当たるのがEvaluationPeriodsです。

1つのデータポイントは1つの期間(Period)に対応するため、アラーム判定の実際の評価期間は、Periodの長さとEvaluationPeriodsの積となります。

例えば、EvaluationPeriodsを10、DatapointsToAlarmを5と設定します。そして1回のPeriod期間を3分とすると、30分間(3 * 10)の評価のうち、15分間(3 * 5)で異常が検出された場合、Alarmが発報されます。

イメージとしては、以下のようなイメージです。

検証

今回は、特定のEC2のCPU使用率を監視します。閾値を50%と設定し、Periodを1分、EvaluationPeriodsを10、DatapointsToAlarmを3としてCloudWatch Alarmを設定し、その挙動を確認します。

$  aws cloudwatch describe-alarms --alarm-names testAlarm
// 省略
{
    "MetricAlarms": [
        {
            // ...
            "AlarmName": "testAlarm",
            "StateValue": "OK",
            "MetricName": "CPUUtilization",
            "Namespace": "AWS/EC2",
            "Statistic": "Average",
            "Dimensions": [
                 {
                     "Name": "InstanceId",
                     "Value": "i-xxxxxxxxxxxxxxxxxxx"
                 }
             ],
            "Period": 60,
            "EvaluationPeriods": 10,
            "DatapointsToAlarm": 3,
            "Threshold": 50.0,
            // ...
        }
    ],
}

stressコマンドで、EC2インスタンスに負荷をかけます。


stress --cpu 8 --timeout 300

以下は、10:34から負荷をかけ、5分後の39分時点のグラフです。

10:37に閾値を超えています。しかし、39分時点ではまだステータスはOKの状態です。これはDatapointsToAlarmを3に設定している為、2ポイント分のデータポイントにおいては閾値を超えていたとしてもAlarm状態にはならないことを表しています。

そして、以下のグラフは負荷開始から10分後のグラフです。

閾値が超えているデータポイントが3以上になったので、Alarmステータスになっていることが確認できました。

活用方法

これらのパラメーターを実際どのように設定するかを考えていきます。

実際のアプリケーションにおいてこれらのパラメーターを適切に設定することができると、システムの監視精度を高め、誤検知を減らすことができます。以下に3つの設定パターンを提示します。

1. 短期間の異常検知

EvaluationPeriodsとDatapointsToAlarmを同じ値に設定することで、短期間でクリティカルな異常を検知することができます。例えば、EvaluationPeriodsを3、DatapointsToAlarmも3に設定すると、3回連続で異常が発生した場合にアラームが発報され、即座に対応が必要な状況を迅速にキャッチすることができます。

2. 一時的な異常の無視

一時的な異常を無視したい場合は、EvaluationPeriodsを多めに設定し、DatapointsToAlarmを少なめに設定します。例えば、EvaluationPeriodsを10、DatapointsToAlarmを3に設定すると、10回の評価期間のうち、2回以下の異常程度であれば無視することができます。具体的な例として、特定の処理によって一時的にシステムが重くなることがあるが、全体としては正常に動いてるシステムがあります。それがある程度許容できるのであればこのようなパラメーター設定でも良いかもしれません。また、この設定により短期間の一時的な異常による誤検知も防ぐことができます。

3. 持続的な異常の検出

逆に、持続的な異常を検出したい場合は、EvaluationPeriodsを多めに設定し、DatapointsToAlarmもそれに応じて設定します。例えば、EvaluationPeriodsを10、DatapointsToAlarmを8に設定すると、12回の評価期間のうち8回以上異常が検出された場合にアラームが発報されます。これにより、システムの持続的な問題を検出することができます。

これらのパラメーターの設定は、実際のアプリケーションの規模や要件によって柔軟に設定する必要があります。